某银行生产和灾备 Power 云化之路 | 最佳实践
【摘要】随着云计算的成熟和广泛落地，为企业 IT 资源带来丰富的敏捷性和灵活的弹性。Power 计算资源作为 IT 资源的一个类型，以其独特的特性和表现， 在 X86 云化的浪潮中依旧有着广泛的应用和生态。本文以某银行生产和灾备Power 云化实践案例为出发点，从起步、进阶、云化、融合、期待等五个 Power 云化过程展开详细介绍，旨在帮助企业深入了解 Power 资源池和云化过程，并结合 Power 服务器和虚拟化技术特性，丰富 Power 私有云平台的功能。
【作者】邓毓，现就职于江西农商银行信息科技部，资深运维工程师，全国第十届 Aix&Linux 高手挑战赛十强，农信银支付清算先进个人，荣获银行业信息科技风险管理课题研究四类成果奖。精通各项运维技术和 IT 基础架构设计，项目经验丰富，运维技术全面，在云计算、双活数据中心、软件定义存储、自动化运维、监控和 OLTP 数据库等领域有深刻的见解和广泛的涉猎。
前言
就目前而言，在银行 IT 基础架构中，Power 服务器因其强大的 RAS 特性， 优异的性能表现以及极少的安全漏洞，在去 IOE 和 U2L 的浪潮中，依然有着一席之地，这点对于国内中小银行、省农信、城商银行尤其如此，其核心业务系统大部分依旧运行于 Power 小型机上，各类关键交易类业务系统数据库依旧更乐意部署于 Power 平台，而不是 X86 平台。
在银行分布式尚未完全成熟和大规模运用之前，笔者认为，Power 和 X86 和谐共存是近些年来和未来相当一段时间内的主旋律。因此，在现阶段我们还是要更多的关注当下，一如既往地搭建好弹性伸缩的Power IT 基础架构，以满足我们现阶段业务发展的需求，和业务连续性的保障。
在大多数银行科技部门，Power 云化是云计算发展成熟之后的构想，云计算发展之初，X86 云是首当其冲的，不仅仅因为其量巨大，横向扩展的需求，让 X86 虚拟化、云化成为大势所趋，更多的是像 Vmware、KVM、Hyper-V、Xen 等虚拟化技术的发展、OpenStack 技术的更新迭代以及近两年的容器技术的飞速进步，让 X86 云和运行在 X86 上的容器云成为必然之选。
而在 Power 云化、容器云化之路上， 虽远不如 X86 来的那么迅猛，但面对如此强调敏捷性、弹性、自动化、平台化的今天，Power 云化也是那么地如此应当。因此，笔者将从我行自身的角度，分享我行在生产和灾备 Power 云化的实践，希望对 Power 资源池、Power 云有需求和致力建设的企业有所帮助。
一、起步：生产Power 物理机 Lpar
我行于 2013 年下半年之前，所有 Power 小型机环境都是物理 Lpar，当时业务种类没有现在这么繁多，核心、交易、管理、开发测试环境总共仅有 30 余个Lpar 分区，承载着核心、柜面、两银、中间业务、银行卡、大小额支付、财管等主要业务系统的生产和测试的运行。新业务系统上线所需资源均是按需供给， 烟囱式的发展，供给周期长，上线周期非常漫长。每台 Power 物理机的 Lpar 分区不超过两个，两个和两个以上则需要购买额外的 IO 卡（HBA 卡和网卡）和 IO 扩展柜，异构 Power 环境比较多。随着业务的迅速发展，购买了大量的 Power 服务器和 X86 服务器，数据中心机房的空间、能耗、制冷问题越来越突出，严重制约了业务的发展速度，单机的性能也逐渐无法支撑业务应用的需求，各种系统、数据库性能调优，系统剥离、迁移工作相继开展，科技人员疲于奔波于日间运维和夜间优化，自建新机房、租用电信 IDC 机房过渡成为了当时面对机房空间问题的唯一选择，设备机房搬迁开展多次。除了基础设施的痛点之外，基础运行环境的准备也是非常耗时耗力，全部人工搭建配置，参数配置不规范，也造成了日后系统各类风险隐患，运维压力巨大。
二、进阶：生产Power 虚拟化和管理试点
面对以上突出的几个问题，我行痛定思痛，2013 年下半年，选择进行虚拟化架构改造和试点上线，首先是对生产存储和 SAN 网络进行改造和整合，在进行存储整合之前，我们的 SAN 网络架构和存储是非常混乱的，生产存储包括了DS3400，DS4700，DS5300，V7000，DS8100 存储和若干套独立的 SAN 网络，交易类系统所用存储都为低端存储，而管理类系统所用存储却反而为当时较高端的DS8100 存储，这些存储都分别为不同的业务系统提供服务，有些比较关键的交易类系统由于上线时间早，都在 DS3400 和 DS4700 上，而这些存储当时已经服役多年，问题不断，一旦存储告警，运维人员都心惊胆颤，特别是在一个主控故障时，更是十万火急赶往现场抢救。为了尽快消除这些存储的单点风险问题，整合所有 SAN 网络和存储，实现存储统一管理和服务分层。我们再三对比不同的方案之后，选择了 SVC 存储虚拟化方案。通过 SVC+DS8870 存储+V7000 存储+B80 交换机，整合了所有 SAN 网络和存储，所有交易类系统存储两份数据，一份在 DS8870，一份在 V7000，整个 SAN 网络架构清晰，冗余度高。同时也因为这次正确的选择为后面的 Power 私有云打下了坚实的基础。
接着我行对生产 Power 服务器进行了 PowerVM 虚拟化和虚拟化管理试点，我行新购买了 2 台 Power 小机和 2 台 PowerLinux 服务器，每个计算节点搭建双Vios，每个 Vios 双网卡和双 HBA 卡，分别接入不同的网络交换机和光纤交换机， 并采用 PowerVM 企业版虚拟化，形成一个小型计算资源池加入 PowerVC 管理；存储资源池上，底层存储划了多个卷给 SVC，SVC 将这些卷组成存储池，提供给PowerVC 管理，正是由于 SVC 的存在，一些不具备接入 PowerVC 条件的存储，都搭了 SVC 这趟顺风车，实现了存储资源池化；网络上，所有计算节点接入的网络交换机端口模式均为 Trunk，提供了一个网络安全分区的多个 VLAN，为 PowerVC 提供网络资源池。最终实现了 PowerVC 对计算资源、存储资源和网络资源的统一管理，在一个网络安全分区内部形成了一个迷你型的 Power IAAS 私有云，并部署了票据、业务报表等新的业务系统。
下图为试点阶段，PowerVC 管理两台 Power 小型机的组网架构，包含业务网络组网、光纤网络组网和带内管理网络组网，每台 PowerAIX 服务器各两个 VIOS， 每个 VIOS 配置两个网卡、两个光纤卡，两个网卡的两个端口进行 Etherchannel 主备模式绑定接入不同的 TOR 接入交换机；两个光纤卡的两个端口接入不同的SAN 光纤交换机；两个 VIOS 配置为 HA 模式，对于业务网络而言，网卡为主备模式，每台服务器的最大带宽为 1Gb，对光纤网络而言，光纤卡为主主模式，虚拟机通过两个 VIOS NPIV 连接存储，总带宽为 8Gb*4=32Gb。带内管理网络方面， PowerVC 通过带内 TOR 交换机与 HMC、SAN 交换机、SVC 连通，实现轻量级管理。
三、云化：生产Power 私有云建设
后面随着 Power 计算节点规模的逐渐扩大，我行又陆续购买了几十台各类Power7、Power8 的 PowerAix 和 PowerLinux 服务器，我行按照网络安全分区的原则，将不同 Power 计算节点按照网络安全分区进行隔离，分为核心区、集中作业区、互联网区、外联区、管理区等，越来越多的新系统数据库和关键应用均落地至 Power 私有云中，涉及我行 80%以上的业务系统数据库和部分应用节点，例如统一柜员、互联网金融、聚合支付、微信营销、卡管、统一支付等等，并逐步将一些老旧系统也迁移至Power 私有云当中。通过 PowerVC 的引入，提升了 Power 资源和存储资源的横纵向扩展能力，并统一和简化了 Power 资源池的管理，其主要表现在以下 4 个方面：
1、架构简单：整个 Power 私有云架构自上而下呈现的是一种松耦合的架构体系，底层计算节点接入网络和存储，通过管理网络接入 HMC 管理，并在 HMC 上搭建好 PowerVM 虚拟化架构，PowerVC 即可通过 HMC 接管计算节点；底层存储划好存储资源池，并在 PowerVC 上配置 SAN 交换机口令，PowerVC 即可接管该存储资源池。PowerVC 直接通过网络管理所有资源，可部署于单台 X86 服务器上， 安装简单，备份方便，无需考虑高可用，脱离 PowerVC，依旧可以手动搭建 PowerVM的 VM，PowerVC 故障不会影响计算节点上的 VM。
2、资源调度多样：PowerVC 是一种轻量级 Power 虚拟化管理平台，既可快速纵向调整业务系统 VM 的资源，也可快速横向扩展应用系统 VM 数量，还可计划性在线迁移 VM 至其他计算节点，减少用户操作量。随着 PowerVC 对底层 Power 其他功能的集成，如 Remote Restart,EnterPrise Pool,PowerHaaS 等，PowerVC 将更加多样的为用户提供便利的资源调度手段，并与传统的手段并存。
3、易用及高效：PowerVC 界面友好，功能清晰，容易上手。PowerVC 部署时可多任务并行，相较于传统的安装式部署，PowerVC 的操作系统安装是以存储快照的方式实现，快照一份操作系统 IMAGE 到虚拟机卷，建立存储数据的指针，虚拟机直接就可以在虚拟机卷上启动了，快照克隆后台自己在同步，可同时快照和同步多份，效率非常高。
4、拥有丰富的对接接口：PowerVC 定位非常清晰，承上启下。针对底层的计算节点，有三种对接方式，第一种是通过 HMC 间接对接 PowerVM 虚拟化；第二种是通过 PowerVC Openstack Nova 对接 PowerKVM 的 Nova 组件；第三种 PowerVC Nova 可以直接通过 NovaLink 的方式对接 Power8 计算节点的 NovaLink 分区。第二种和第三种是 Nova 之间的通信，效率最高。针对上层的云管理平台层，PowerVC提供了 PowerVC adapter，OpenStack 框架下的云管理平台需要集成 PowerVC adapter 即可实现轻松对接。
四、云化：灾备Power 私有云建设
生产 Power 私有云化的整个过程比较平稳顺利，效果也很显著，大幅缩短了Power 环境的部署时间，相比较之前按业务需求购买的 Power 资源配置，新加入私有云的计算节点资源配置都大幅提升，从之前单台 Power7 的 4C16G、4C32G 和 8C64G 等标准直接提升至 Power8 的 24C512G 和 24C1024G，虚拟机的纵向扩展由了足够的空间，不再受困于单台物理机的资源限制。
我行从 2015 年下半年开始筹备交易类业务系统的同城灾备环境建设，灾备Power 私有云也是建设的重点工作之一。灾备环境运行于我行新数据中心，将来需要将现有生产环境全部切换至灾备环境，因此灾备环境和生产环境为 1：1 配置，为了保证未来的生产环境 IT 基础架构的稳定性和可靠性，相较于生产 Power 私有云，灾备 Power 私有云的建设有以下 3 个不同之处和亮点：
1、生产每台 Power 服务器均配置为 4 张 4 电口千兆网卡，而灾备 Power 服务器配置为 4 张 2 千兆电口 2 万兆光口的网卡。如下图所示，每个 VIOS 配置两块此类网卡，VIOS 配置 2 个 SEA，一个 SEA 用于业务，一个 SEA 用于带内管理。业务的 SEA 通过一组 Etherchannel 连通物理千兆网络环境，带内管理的 SEA 通过一组 Etherchannel 连通物理万兆网络环境。千兆 Etherchannel 通过两个网卡的三个电口绑定，形成主主备模式，最大带宽 2Gb，千兆 TOR 交换机的两个主主端口配置 LACP。万兆 Etherchannel 通过两个网卡的两个光口绑定，形成主备模式，最大带宽 10Gb。业务网络和带内管理网络充分隔离，带内管理网络主要用于数据传输和管理，例如 GPFS 并行文件系统、DB2 HADR、备份、网络心跳、数仓抽数等等。这样对于交易类的业务而言，单台 Power 计算节点能够提供的最大带宽，可以满足我行现阶段单台计算节点虚拟机的业务流量总和要求；对于数据管理而言，充足的万兆带宽可以满足大量数据的吞吐量要求，并减少传输时间。
2、灾备 Power 资源池全部采用了 Power8 以上的服务器，后期陆续十几台Power9 的服务器也将到位，均配置了先进的 Power 远程重启技术（SRR），交易类应用或数据库节点均匀分布于多台 Power 计算节点，某计算节点故障宕机，其上承载的节点可自动迁移至其他计算节点中继续运行。在 PowerHA 高可用或者应用集群等高可用保护之上，在 Power 资源池层面进一步加固。这样可以防止在单台计算节点异常时，持续提供完全的性能和高可用保护能力，例如一个两节点的WAS 集群分布于两个 Power 计算节点，当一个计算节点故障时，其上的 WAS 虚拟机将通过 LPM 迁移至另一个计算节点启动，两个节点的 WAS 集群继续提供完整性能的服务。又例如一对配置了 PowerHA 的两个数据库节点分布于两个计算节点， 一个计算节点异常时，PowerHA 将其上的资源组切往另一个计算节点的虚拟机， 并通过 LPM 将自身虚拟机迁移至另一个计算节点，两个 PowerHA 架构下的虚拟机重新组成高可用模式。
3、灾备 Power 私有云搭建了多个 PowerVC 分别管理不同安全分区的 Power 资源池，分为集中作业 PowerVC、外联 PowerVC、互联网 PowerVC 等等，并和不同资源池之上的多个 HMC 一一对应，避免了一套 PowerVC 管理下的性能瓶颈。
五、融合：生产和灾备统一Power 云管平台
为了将生产和灾备 Power 私有云（多套 PowerVC）、Vmware X86 私有云、KVM X86 私有云统一管控，形成一朵大云，利用先进的平台对所有资源进行全生命周期管理和统一编排，我行基于商用 OpenStack 产品，搭建了一套统一云管平台， 形成一整套云计算体系，该云体系基于 OpenStack 框架，其主要部件的功能如下：
1、PowerVC 是 IBM 在 OpenStack 商业发行版上基于 Power 特性定制的 Power 虚拟化管理平台，定位为 Power IaaS 云，在整个云体系中，起着承上起下的作用。启下方面，PowerVC 中的 Nova 组件和底层 HMC 通讯完成 Power 计算节点的管理和部署工作；PowerVC 中的 Cinder 组件和底层的存储通讯完成存储资源池的管理和分配工作；PowerVC 中的 Neutron 组件和 PowerVM 协调完成网络资源的分配和划分工作。承上方面，上层的 OpenStack 可以集成 PowerVC Adapter，来与PowerVC 的各个组件通讯，并将PowerVC 中的计算实例和存储资源逻辑上接管， 来完成跨层的部署和管理工作。
2、ICM(Cloud Manger)最重要的特色是异构的管理，这个异构可以是虚拟化技术间的异构管理（如 PowerVM 和 KVM），也可以是虚拟化管理平台的异构管理
（如 PowerVC 和 Vcenter），也可以是虚拟化技术和虚拟化管理平台异构的结合。可见十分强大，ICM 定位为异构平台的 IaaS 云，也是 IBM 在 OpenStack 的商业发型版的基础之上，定制开发的一款云管理软件。为了实现 ICM 的物理隔离和功能解耦，我们对 KVM X86、Vmware X86 和 Power 三种不同类型的资源池分别指定了 ICM，分别控制，任何一套 ICM 不可用，均不会在 IaaS 层对其他资源池的部署和管理造成影响。但是其中一套 ICM 指定为逻辑的主 ICM，其他的 ICM 在逻辑上指向该主 ICM，实现门户的统一，提升管理的便捷度，并有利于对接上层云管平台。
3、ICO（Cloud Orchestrator）是整个云体系中的最高层次---统一云管平台，在这个层次的云管平台主要是实现资源的全生命周期的管理，提供了云的各类服务，如统一监控、统一流程、服务目录、容量管理、计费和统一门户的功能等等。ICO 作为 IBM 向外推广的云管平台的一种，最重要的部分在于 ICO 能够协调 ICM 中内嵌的 OpenStack Heat 组件，OpenStack Heat 是一个基于模板来编排复合云应用的组件，服务模板的使用简化了复杂的基础设施、服务和应用的定义和部署。Heat 模板支持丰富的资源类型，实现了对操作系统的自动化配置、并安装配置应用、中间件、框架和工具等，实现了部署的统一规范。最终 ICO+ICM可以实现 PaaS 级异构私有云。
六、期待：Power 云化的问题与展望
我行的 Power 云化的道路依旧还在继续，在这个过程中，我行也的确遇到了许多挑战和问题，希望在之后的优化之路上，继续提升整个 IT 资源管理和运维服务能力。现阶段而言，主要问题和对 Power 今后的展望体现在以下几个方面：
1、关于资源信息的同步问题。
由于自下而上存在多级管理平台，存在多级管理平台的接口对接和信息传递的问题，比如说 HMC-PowerVC-ICM-ICO 这是一条PaaS Power 云自下而上的层次关系，在部署虚拟机时，ICO 首先调用 ICM 的接口， ICM 的 Nova 组件调用 PowerVC Adapter，然后 PowerVC 调用底层的 HMC 创建 Lpar 分区，调用 SAN 交换机划 Zone，调用 SVC 存储资源池创建存储卷，最后创建成功后从底层将信息返回至 PowerVC，再至 ICM 和 ICO，来保持多个管理平台的信息一致性。倘若底层手动直接更改了虚拟机的信息，由于 PowerVC 和 HMC 间不具备自动同步机制，底层手动更改的信息无法同步回最上层，会造成上层和底层信息不一致的现象，造成管理的问题。
这里可以分两点来说明该问题，一是在底层直接手动部署，比如在 HMC、SAN 和存储上手动部署 PowerVM 的虚拟机，这时在PowerVC 上或者 ICM/ICO 上是不存在部署虚拟机的信息的，你可以手动将符合条件的虚拟机逐级纳入上层管理平台管理，这里的信息不同步问题可以手动解决， 这点也符合整个云体系松耦合的特性；二是之前通过最上层的 ICO/ICM 部署完虚拟机，部署完毕后，各个管理节点的信息这时是完全一致的，倘若此时在底层直接修改了虚拟机信息，比如通过 HMC 修改了 Lpar 虚拟 Adapter 的 VLAN ID 等， PowerVC 无法自动获取该信息，导致 PowerVC 和上层的ICM 与底层的信息不一致， 这时是有问题的，一来管理上信息不匹配，导致容量管理上出错，经常这样修改底层时，会导致最上层管理的信息无用，不可信，最后逐渐失去了统一管理的作用；二来可能会导致系统无故重启的问题，带来重大隐患，我们在测试云中发现了该问题，由于在 HMC 上更改了 Lpar 的信息，而 PowerVC 上并没有同步该信息， 造成频繁重启的异像，最后分析发现，重启的元凶是 PowerVC。所以后面，我们除了一些必须到底层去更改的操作，其他都严格要求必须在最上层进行部署和信息变更。
2、关于 Power 计算资源更加”Open”的展望。
目前，在 Power8 的小型机中已经开始支持通过 NovaLink 的方式与上层的 OpenStack 对接，这样对接方式， 效率更高，OpenStack 平台的 Nova 组件可以直接对接 Power8 计算资源，摆脱之前只能通过 HMC 管理计算资源的窘境，像 PowerVC 和其他 OpenStack 平台可以绕过 HMC 进行管理和部署工作，这样的架构扁平化和精简化。
但是目前只有 Power8 才能支持这样的方式，其他的 Power 依旧需要 HMC 的对接方式，另外即使有了NovaLink，目前还依旧需要 HMC 进行硬件的管理，两个方式可以并存。通过这一点可以看到厂商想要使得 Power 资源更加“Open”，不再是封闭，难以对接。我行将来也会仔细研究这种方式，看是否能够对现有架构进行再优化。
3、关于 Power 云与 Power 特性结合的展望。
目前 Power 云的功能主要是PowerVC 所展示和提供的，比如目前可以实现的资源的横纵向扩展、动态迁移 LPM 等，但 Power 的特性远远不止于此，PowerVC 现在和将来会充分结合 Power 服务器的功能特性，内嵌部分 Power 平台独特的高级功能，并以更便捷和简单的方式呈交给用户使用，比如 PowerVC 中嵌入 PowerHA 功能插件，能够将 Power HACMP 作为一种服务（HaaS），交付给用户，在部署 IaaS 资源时，也同时将 HA 高可用部署好，同时在部署完成后，在 PowerVC 上能够提供可视化界面，展示高可用的架构。又如 PowerVC 资源池可进一步结合 Power EnterPrise Pool，实现 Power 计算资源（CPU 和内存）许可的跨服务器灵活分配，让用户购买的计算资源“移动化”，帮助企业用户实现业务错峰、日间和日终资源切换和灾备等场景，帮助企业节省大量采购成本。
不仅如此，PowerVC 资源池还可以实现Power Enterprise Pool+PowerHA 的组合，实现故障和资源许可同时切换，自动将登记资源迁移至失效接管系统，实现资源重分配和高可用的完美结合。可是遗憾的是，目前而言这项技术只能运用于 Power770+,780+,E870 和 E880 高端机型当中，希望这项技术能够在将来不远能够下移至中低端机型。
可以看到，Power 云在目前和今后不断的改进中，无论是计划性的跨计算节点动态迁移（LPM），还是非计划性的跨计算节点故障切换转移（Hacmp），还是非计划性的跨计算节点远程重启（Remote Restart），还是故障和资源许可的同时转移（HA+EnterPrise Pool），可以形成一整套高可用解决方案，为 Power 资源池提供更全面和更灵活的高可用保护。基于以上这些，我行也将再接再厉，积极跟进和研究最新技术前沿，为业务系统提供更加周全缜密的高可用保护。
如有任何问题，可点击文末阅读原文到社区原文下评论交流
资料/文章推荐：
PowerVC云概述
http://www.talkwithtrend.com/Document/detail/tid/421087
【红皮书】使用IBM PowerVM和IBM PowerVC构建无SAN的私有云
http://www.talkwithtrend.com/Document/detail/tid/420929
企业入云策略前瞻
http://www.talkwithtrend.com/Article/244615
欢迎关注社区以下 "灾备"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/3457
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场